Skip to content

feat(se050-ed25519-jcs-receipt): NXP SE050 reference Ed25519 signed-receipt example#2

Open
tomjwxf wants to merge 1 commit intomainfrom
feat/se050-ed25519-jcs-receipt
Open

feat(se050-ed25519-jcs-receipt): NXP SE050 reference Ed25519 signed-receipt example#2
tomjwxf wants to merge 1 commit intomainfrom
feat/se050-ed25519-jcs-receipt

Conversation

@tomjwxf
Copy link
Copy Markdown

@tomjwxf tomjwxf commented Apr 19, 2026

Companion to #1 (ATECC608B / ECDSA P-256 example). SE050 supports Ed25519 natively in hardware, which is the IETF draft's mandatory-to-implement algorithm. Receipts from this signer verify directly against @veritasacta/verify without needing ES256 adapter support.

Same decomposition as #1

  • Device signs pre-hashed 32-byte digests, nothing else
  • Host-side Python handles JCS canonicalization + envelope assembly
  • 64-byte Ed25519 (R || S) signature crosses I2C

What's in the box

  • src/receipt_signer.{c,h} — thin nxp-plugandtrust wrapper (init, sign 32-byte digest via sss_asymmetric_sign_digest, read pubkey, release)
  • src/example_main.c — CLI that signs a hex digest from argv given a persistent object ID
  • host/build_receipt.py — three modes:
    • reference — byte-reproducible sample using software Ed25519 with deterministic seed
    • build — given a device pubkey, prints canonical envelope + SHA-256 digest to feed the device
    • assemble — given device's signature + pubkey, emits the final receipt JSON
  • sample_receipt.json — pre-generated reference output (598-byte canonical, Ed25519-verified)
  • Makefile — Linux host build against installed nxp-plugandtrust

When SE050 vs ATECC608B

Property ATECC608B SE050
Native Ed25519 No Yes
Price @ 10K volume ~$0.60-$0.80 ~$1.20-$2.00
SDK cryptoauthlib (MIT) nxp-plugandtrust (BSD-3)
Linux / Zephyr story Good Better
Typical use IoT, Matter Pharma, supply-chain attestation

Tradeoff documented in README. Both examples coexist as parallel references — pick the chip that matches your cost / algorithm / SDK constraints.

Tested

  • python3 host/build_receipt.py reference produces a 598-byte canonical envelope with SHA-256 digest 8310e6166a5851c8f0ab21739a4fdf32d6f94180cad891d53770c9b692a469d1
  • Signature independently verified against cryptography.hazmat Ed25519 verify
  • C code compiled-checked against nxp-plugandtrust SSS API surface (2026-04 main); real-hardware verification pending first SE050 dev-board acquisition

Related

…xample

Companion to the ATECC608B example (PR #1). SE050 supports Ed25519
natively in hardware, which is the IETF draft's mandatory-to-implement
algorithm. Receipts emitted from this signer verify directly against
@veritasacta/verify without needing ES256 adapter support.

Same host/device decomposition as the ATECC608B example:
- Device signs pre-hashed 32-byte digests, nothing else
- Host (Python) handles JCS canonicalization + envelope assembly
- 64-byte Ed25519 R||S signature crosses I2C

Files:
- src/receipt_signer.{c,h}: thin nxp-plugandtrust wrapper
  (init, sign 32-byte digest via sss_asymmetric_sign_digest, read pubkey)
- src/example_main.c: CLI that signs a hex digest from argv
- host/build_receipt.py: canonicalizer + reference fixture generator
  (deterministic seed -> byte-reproducible sample_receipt.json)
- sample_receipt.json: 598-byte canonical envelope, signature
  cross-verified against cryptography.hazmat Ed25519 verify
- Makefile: Linux host build against installed nxp-plugandtrust

Decision when to use SE050 vs ATECC608B:
- Ed25519 native required (IETF spec conformance, pharma, regulatory) -> SE050
- Cost dominates at volume, ECDSA P-256 + ES256 adapter acceptable -> ATECC608B
- Documented tradeoff table in README.

Tested:
- host/build_receipt.py reference produces reproducible 598-byte envelope
- SHA-256 digest: 8310e6166a5851c8f0ab21739a4fdf32d6f94180cad891d53770c9b692a469d1
- Signature independently verified via cryptography.hazmat Ed25519
- C code compiled-checked against nxp-plugandtrust SSS API surface;
  real-hardware verification pending first SE050 dev-board acquisition
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants